1. Field of the Invention
The invention is directed generally towards the controlling of the execution of process steps and more specifically towards controlling of process steps performed via a computer system where users specify a representation of the process whose execution is controlled by the computer system.
2. Description of the Prior Art
A process is an ordered set of steps to be followed in attaining an end. The end of the process may be an article of manufacture, an item such as a computer program, a business plan, or a design, or a change of status (for example, a permit to begin construction). In the following discussion, developers is used to refer to the humans who carry out the process.
Processes may vary across organizations and systems. A process step corresponds to a set of events that occur on entities. When the process involves a computer, many of the events will occur within the computer system. We say that a step has occurred when the corresponding set of events have occurred. For example, a process step may correspond to the invocation of a particular software tool on a particular entity to accomplish a task, such as a manager reviewing and formatting a document using an editor. In this case, the software tool is the editor and the step corresponds to the following events: the manager invokes the editor, the editor opens the document, the manager modifies the document, and finally the manager terminates the invocation of the editor. A process step may also correspond to events that occur outside the computer system, such as holding a decision-making meeting; the beginning and completion of the step must be announced explicitly by a user.
Typically, the steps of a process must be carried out in a particular order. The ordering is not necessarily serial; steps can occur in parallel. Additionally, the ordering can either be partial (only some steps must be executed in a particular order) or total (the ordering of steps is strict).
Work in the field of process control has focused on two aspects: (1) devising useful notations, called process modeling languages, by which the desired process is specified; and (2) investigating process control mechanisms by which computers may assist users in carrying out the specified processes.
A process control system is a computer system that provides a process modeling language for specifying processes and provides computer-aided control over the execution of such processes. A variety of process modeling languages have been proposed, including rule-based languages, Petri Net-based languages and procedural languages. The forms of computer-aided process control also vary; existing process control systems can: (1) monitor the actual development of the end product in order to verify that users are following a particular process; (2) automate parts of the process; and (3) enforce a specific process.
As mentioned earlier, a process step may correspond to events that occur on entities that are within the computer system or outside it. Monitoring is possible only for entities accessible from the computer system. These include files, devices, and executable programs. The process control system must be notified about the occurrence of the events that occur on these entities. This notification can be done in a variety of ways. One way is to force the activities that cause the events to send messages announcing the occurrence of events. Another way is by simply having the user directly notify the process control system of the occurrence of events. A third way is to have the occurrences of such events (for example, the contents of a file changing) automatically detected and reported to the process control system. All prior-art process control systems known to the inventors use one of the first two approaches. The invention described herein uses the third approach.
Automation and enforcement of the process depend on the ability of the process control systems to monitor the process. The system automates parts of the process by automatically performing steps that developers would have performed manually. Enforcement ensures that the performance of process steps follows the specified ordering of the steps.
These forms of computer-aided process control, if provided in as non-intrusive a manner as possible, are particularly useful in supporting software engineering, design and project management processes. Several process control systems have been proposed and some have been built in the past few years. Many of these systems are described in various papers in Proceedings of the Eighth International Software Process Workshop, Schaefer (ed.), Wadern, Germany, March, 1993.
We divide the prior art into two categories: the monolithic process control system approach and the tool-based process control system.
In the monolithic approach the process control system is a stand-alone entity that does not interact with external components. In this approach, developers work entirely within the environment created by the process control system; i.e., all interaction between the developers and the tools used to develop the end product is done via the process control system. Users execute all process steps directly and explicitly notify the process control system about all process related events. The advantage of this approach is that it allows complete control of the process. The control extends to events that do not correspond to tool invocations. The consequence of this approach, however, is that the tools that perform process steps, e.g., editors and compilers, must all be somehow made part of the process control system.
One example of this approach is the Marvel system described by Naser Barghouti and Gall Kaiser in "Scaling Up Rule-Based Development Environments", Proceedings of the Third European Software Engineering Conference, Milan, Italy, 1991, pp. 380-395. Another example is Process Weaver described by Maryse Bourdon in "Building Process Models using PROCESS WEAVER: a Progressive Approach," Proceedings of the Eighth International Software Process Workshop, Wadern, Germany, March, 1993, pp. 40-42.
FIG. 4 depicts the tool-based approach. The process control system in this approach consists of four major parts: a Process Server (101), a Policy Translator (403), a Message Multicaster (408) and a set of Tool Envelopes (405).
The Process Server (101) conveys to the Policy Translator (403) the set of events corresponding to process steps that must be monitored (402). These events correspond to actions carried out by any of a particular set of tools (404) used by the developers. An example of such an event is an editor modifying a particular file. Policy Translator (403) translates these events into a set of tool messages that should be monitored (407). This set of tool messages is stored in the Message Multicaster (408), which then monitors the specified tool messages. An inherent problem of the tool-based approach is that it can only monitor events produced by a fixed set of tools. Events produced by other entities or by users of the system cannot be monitored.
A tool (404), such as an editor, typically does not send messages indicating the actions it has performed, such as modifying a file. Since such messages are required for monitoring, the tools (404) are enveloped. A tool envelope (405) is written by a user to encapsulate a tool (404). An envelope sends messages to interested parties, such as process control system, about actions performed by the tool. For example, an editor envelope could send a message to interested parties notifying them that it has modified the contents of a particular file. The concept of envelopes was disclosed by Mark Dowson in "Integrated Project Support with IStar," IEEE Software, volume 4, number 6, November, 1987, pp. 6-15. Another example of tool enveloping has been disclosed by Steve Reiss in "Connecting Tools Using Message Passing in the Field Environment", IEEE Software, July 1990, pp. 57-66.
The messages (406) generated by the tool envelopes (405) are sent to the Message Multicaster (408). The Message Multicaster (408) matches these messages against the tool messages it has to monitor (407) and informs the Policy Translator (403) via tool message notifications (409). The Policy Translator processes these tool message notifications and converts them to event notifications (410), which are sent to the Process Server (101). The Process Server (101) uses these notifications to control the process under purview.
The tool-based approach removes the restriction that all development has to be done from within the process control system. This has the advantage of allowing users to use the tools of their choice, given that envelopes have been provided for the tools. See D. Garlan and E. Ilias in "Low-cost, Adaptable Tool Policies for Integrated Environments", Proceedings of the Fourth ACM SIGSOFT Symposium on Software Development Environments, Irvine, Calif., 1990. pp. 1-10.
Both of the approaches in the prior art suffer from major drawbacks. The monolithic process control system approach assumes that organizations adopting process technology will alter their working environment significantly. The reason is that developers must now interact only with the process control system instead of the tools with which they are familiar. Events corresponding to process steps that occur outside the process control system cannot be tracked unless the users explicitly notify the process control system about them.
It is very difficult to convince developers to move to a completely new environment, especially when the advantages of process control system environments over more traditional environments have not yet been demonstrated. Furthermore, the need to make everything usable within the process control system environment has made it difficult to integrate existing technology or use new technology.
The tool-based approach requires that all tools used must be enveloped to permit interaction via a centralized message server. The developers thus cannot use a new tool without enveloping it. It is difficult to keep track of which tools have been enveloped and which have not, especially in organizations where tools are updated and modified frequently. Further, enveloping a tool may not always be straightforward and may require considerable human effort.
What is needed, therefore, and what the art has not yet provided, is an open process control system that permits a user to retain his/her current working environment (e.g., all the tools in the system), automatically detects events on entities of interest to the process, and uses this information to control the process.